アジャイルイントロダクション : Agile 開発の光と影
著 : Bertrand Meyer
原著 : Agile! The Good, the Hype and the Ugly
https://m.media-amazon.com/images/I/41stvGbZbSL._SX260_.jpg
Amazon : https://amzn.to/3LCWkRf
感想
訳が日本語としておかしい部分がちょくちょくある
ソフトウェア工学は、「ソフトウェア危機」 が認識され、1968 年頃がその起源である。
とか
内容メモ
本書の内容
アジャイルの考え方を紹介し、包括的な評価をする
アジャイルについて説明
ウォーターフォール型開発などの伝統的な計画に基づくソフトウェア工学の手法の概要を説明
アジャイルな考え方を検証 : アジャイルの原則、役割、プラクティス、成果物
代表的な手法 : スクラム、リーンソフトウェア開発、XP、クリスタル
組織がアジャイル開発を適用する際に気を付けるべきこと
最終的な評価
1 章 概要
アジャイル開発は、単一の開発手法を示す言葉ではない
アジャイルの信条
アジャイルの核となる 8 つの原則
アジャイルの役割
主要なアジャイルのプラクティス
重要なアジャイルのツール
アジャイルに対する概評
2 章 アジャイル文章の分析
アジャイルの書籍でよく使われる言葉のトリック 7 選
3 章 敵は大掛かりな事前作業の全て
アジャイル提案者が敵視する計画主導について
4 章 アジャイルの原則
原則として適格なもの
良い方法論の原則は、抽象的であると同時に反証可能であること
抽象的 : 原則とプラクティスの違い
プラクティスは原則を実現する手助けとなるもの
反証可能 : 常識との違い
分別のある人がその原則に同意しないこともあることを意味する
誰もが同意するようなものは常識であり、興味を持たれない
公式の原則 : アジャイル宣言の背後にある原則
いくつか不足がある
プラクティスが含まれていたり、常識が含まれていたり、規範的でなく主張があったりする
代わりにアジャイルの核となる 8 つの原則を使う
二重開発
5 章 アジャイルの役割
アジャイルの役割
メンバーとオブザーバー (豚と鶏)
ハーラン・ミルズ (Harlan Mills) は、1971 年にチーフプログラマというコンセプトを開発
アジャイルの役割についての評価
最も面白いのは、管理者からプロダクトオーナーの役割を分離したこと
以下 2 つを分けるのは有用
日々のプロジェクトの方向付け
ビジネスのために何をすべきか定義し、それが実行されているかを確認すること
整合性と独立性のトレードオフ
1 人が両方を見る方が整合性を取れるが、2 人の方が独立性が高い
他の役割についても、統合するかどうかをトレードオフで検討できる
6 章 管理者のプラクティス
アジャイルにおけるプロジェクトの組織とマネジメントに関するプラクティス
7 章 技術的なプラクティス
アジャイルにおける技術的なプラクティス
アジャイルに取り組む人たちは新しい考えを生み出している
Thrashing や Anarchy、No Estimates なども
8 章 アジャイルの成果物
アジャイル開発においてプラクティスを支援するアーティファクト
9 章 アジャイル開発
アジャイル開発 (カンバンやリーンソフトウェア開発、XP、スクラム、クリスタルなど) は、規律やプラクティス、役割やアーティファクトといった構成要素の組合せ
10 章 アジャイルチームの扱い
『Software Estimation: Demystifying the Black Art』 (和訳 : ソフトウェア見積り 人月の暗黙知を解き明かす) で言われるように、コストをかけても開発時間の短縮は一定程度までしかできない
アジャイルではタイムボックスの考え方を適用している → 機能と時間のどちらかしか保証できない
実際のところ、顧客がそれを受け入れるのかという問題がある
優秀なチームは、1 年以上、絶えず予算内で適切な機能を定刻通り提供できる
プロとアマチュアの違い
組織をアジャイルに変遷させる中で、アジャイルチームに責任を負ってもらうようにするのがデリケートな問題
合理的には、ゴールを中間的なステップ (マイルストーン) に分割する
11 章 アジャイル開発の評価 : 難点・誇張・利点
アジャイル開発の難点
事前タスクの軽視 (特に事前要求と事前設計)
要求の基本としてのユーザーストーリー
抽象化を捨てている
機能単位の開発と依存関係の無視
依存関係追跡ツールの拒絶
ガントチャートなど
従来の管理者 (マネジャー?) のタスクの拒絶
事前の一般化の拒絶
オンサイト顧客
個別の役割としてのコーチ
テスト駆動開発
テストファーストやリファクタリングは良い
テスト駆動開発のプロセスは真剣には取り組まれないし、そういった取り組みを用いると最新のテストに注目することにより視野を狭めうる、とのこと
nobuoka.icon いまいちわからん
ドキュメントの軽視
アジャイル開発の誇張
ペアプログラミング
オープンスペース
自己組織化チーム
持続可能なペースで作業する
最小の機能を生産する
計画ゲーム、プランニングポーカー
メンバーと観測者の区別
コードの共有 (コードの共同所有)
機能横断型チーム
アジャイル開発の利点・素晴らしい点
利点
リファクタリングの推奨
デイリーミーティング
チームのコミュニケーションの重要性
障害や無駄を識別して取り除くプラクティス
素晴らしい点
短いイテレーション
閉じられた窓のルール
タイムボックス化したイテレーション
ベロシティとタスクボード
プロダクトオーナーという概念
継続的インテグレーションと回帰テストスイート
機能の全てにテストを記述すること
動作するソフトウェアを納品すること
#アジャイル #トップエスイーシリーズ #書籍 #文献